home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001271_daemon _Mon Jun 14 11:21:54 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA27422; Mon, 14 Jun 93 11:21:56 MET DST
  3. Return-Path: <marca@wintermute.ncsa.uiuc.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA27418; Mon, 14 Jun 93 11:21:54 MET DST
  6. Received: from newton.ncsa.uiuc.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA20057; Mon, 14 Jun 1993 11:43:58 +0200
  8. Received: from wintermute.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA09285
  9.   (5.65a/IDA-1.4.2 for timbl@nxoc01.cern.ch); Mon, 14 Jun 93 04:43:47 -0500
  10. Received: by wintermute.ncsa.uiuc.edu (920110.SGI/911001.SGI)
  11.     for @newton.ncsa.uiuc.edu:Damian.Cugley@prg.ox.ac.uk id AA16011; Mon, 14 Jun 93 04:46:28 -0500
  12. Date: Mon, 14 Jun 93 04:46:28 -0500
  13. From: marca@ncsa.uiuc.edu (Marc Andreessen)
  14. Message-Id: <9306140946.AA16011@wintermute.ncsa.uiuc.edu>
  15. To: timbl@nxoc01.cern.ch
  16. Cc: Damian Cugley <Damian.Cugley@prg.ox.ac.uk>, www-talk@nxoc01.cern.ch
  17. Subject: Re: SPaces and Tabs in HTML documents
  18. In-Reply-To: <9306140908.AA01588@www3.cern.ch>
  19. References: <9306140908.AA01588@www3.cern.ch>
  20. X-Md4-Signature: 864bd29e50af0e75ac95965a8459430d
  21.  
  22. Tim Berners-Lee writes:
  23. > >So far as I can tell, the HTML specification makes no mention of how
  24. > >duplicated spaces and tabs are to be treated in HTML documents.
  25. > 
  26. > You are right.  Actually tabs are mentioned in the PRE part, but
  27. > nowhere else.   The general understanding (before Mosaic) was that
  28. > 
  29. >     - Multiple spaces should be respected as such (for example
  30. >       some people like them around punctuation) and should not
  31. >       be used for prettying up the source.
  32. > 
  33. >     - Tabs should not be used outside PRE
  34. > 
  35. >     - Within PRE, tabs are normal unix
  36. >         (>0 spaces to multiple of 8)
  37.  
  38. The general understanding before Mosaic??  The general understanding
  39. we were under was that redundant spaces, newlines, tabs, etc. were not
  40. significant, and that's the way Mosaic treats 'em.  The concept that
  41. multiple spaces should be respected as such is new to me -- where in
  42. the online info was this stated?
  43.  
  44. > I would like to specify that multiple spaces be interpreted as such.
  45. > Would this be a big problem for anyone?
  46.  
  47. Isn't it a violation of the SGML philosophy that we've all spent so
  48. much blood, sweat, and tears trying to adhere to?
  49.  
  50. If we're going to start down this path, I'd like to see a line
  51. containing nothing but whitespace to be considered an implicit
  52. paragraph separator (<p>), as in LaTeX.
  53.  
  54. > >    <p> Also, the two browsers have different ideas about whether the
  55. > >    ADDRESS tag marks a new paragraph or not -- www puts the address
  56. > >    flush right in a new paragraph, Mosaic simply switches to a
  57. > >    different typeface.
  58. > 
  59. > There is in the hypertext document (and in the draft internet draft)
  60. > a "typical rendering" defined for each of these elements.  Browsers
  61. > are not obliged to use this rendering. In the case of Mosaic, as far
  62. > as I can see, nothing is ever justified other than left-justfied.
  63. > That may be just the desiner's choice or a constraint of the  
  64. > implementation.  It doesn't make them an invalid W3 browser, just
  65. > not a typical one.  (Even though there may be -- untill Cello gets
  66. > seriouslsy deployed -- more XMosaics than anything other W3 clients)
  67.  
  68. It was a choice, made at least partially because documents can be
  69. wider than the available window space, causing a horizontal scrollbar
  70. to show up and info on the right side of the document to be hidden until
  71. the window is scrolled.  Didn't seem reasonable that information
  72. should be shoved over where one might not even be able to see it.
  73.  
  74. > The ideal would be to make the styles user-configurable, with the
  75. > "typical rendering" and the designer's personal favorites
  76. > as an options.
  77.  
  78. Agreed.
  79.  
  80. Marc
  81.